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Remarks 

A. Cited Art 

U.S. Patent No. 6,546,419 to Humpleman et al. ("Humpleman") entitled "Method and 
Apparatus for User and Device Command and Control in a Network." 

Background 

Claims 25-34, 36-55, and 57-62 were rejected under 35 U.S.C. § 102(e) as being 
anticipated by Humpleman. Applicants have amended the following claims 25, 32, 33, 38, 42, 
48, and 59. Claims 28-29, 43, 49, 54-55, 57, and 60-62 have been canceled, and Applicants have 
added 63-72. Thus, claims 25-27, 30-34, 36-42, 44-48, 50-53, 58-59, and 63-72 are pending in 
the application. The independent claims are 25, 32, 33, 38, 42, 48, and 5 1 . Reconsideration of 
the application is respectfully requested in view of the foregoing amendments and following 
remarks. 

C. Patentability of the Claims 

35 U.S.C. 5 \02(e) - Humpleman 

Applicants respectfully note that independent claims 25, 32, 33, 38, 42, 48, and 51 have 
been amended. 

Furthermore, Humpleman does not teach or suggest all of the elements of the pending 
claims. For example, Humpleman does not teach or suggest "generating a service control 
protocol in accordance with the service control protocol definition to interact with the user- 
selectable service, wherein the service control protocol comprises plural network messages 
having a content and a sequence used to interact with the user-selectable service" as recited in 
claim 25. As described in the specification, implementations of the pending patent application 
involve "all (UPnP) Controlled Devices or Bridges) expos[ing] one or more Services that can be 
controlled remotely. Controlling such Services involves a message exchange between a User 
Control Point and the device. This message exchange happens according to a specific Service 
Control Protocol (SCP), which specifies the content and sequence of the messages exchanged." 
(Specification, page 44, lines 12-18). 
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Moreover, "User Control Points are not required to have any prior knowledge of the 
SCPs required to control the Services on the various devices. Therefore, a Controlled Device or 
Bridge must be able to describe to a User Control Point the protocols required to control its 
Services, such that the User Control Point will be able to implement these protocols dynamically. 
This requires a standard way of declaring Service Control Protocols in a concise and 
unambiguous fashion. UPnP introduces a technique for declaring Service Control Protocols 
using a series of XML documents." (Specification, page 44, lines 19-26). 

"As part of the Service Definition, a Service State Table and Command Set are defined 
These things can be combined in a deterministic way defined by UPnP to produce a Service 
Control Protocol Definition (SCPD), which includes a Service Control Declaration and a Service 
Control Protocol. The SCPD is a representation of the schema of a Service." (Specification page 
45, lines 1-5). 

"The SCPD is directly embedded into the Description Document of a Controlled 
Device." When the Description Document, including the SCPD is uploaded into a User Control 
Point, data from the SCPD can be extracted to know how to generate service specific service 
control protocols. (Specification, page 45, lines 13-17) 

The process of declaring Service Control Protocols involves S6 obtain[ing] a data 
description or declaration of the methods, properties and events of the remote service, as well as 
a definition of the protocol of network data messages through which the . . . methods, queries 

[are invoked] or ... the properties [set] [T]his data description takes the form of the 

Description Document, which contains a Contract." (Specification, page 45, lines 25-27). For 
example, "[t]he Contract defines network data packets (e.g., XML data), request/response 
patterns, and protocol ... via which the packets are exchanged. This information is sufficient 
. to exchange the appropriate network data packets to interact with the Controlled Device 
Service, including to invoke commands, query and set properties, and receive and respond to 
events, without download of any executable code to the User Control Point device and with a 
zero installation or configuration experience." (See Specification, page 45, line 27 - page 47, line 
7). 

Humpleman does state, however, that its "INTERFACE- A.XML [document] can also be 
used by a foreign Application such as Service B to determine the message format for Service A 
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before communicating with the Service A." (See Humpleman, col, 13, lines 3-6). Humpleman, 
however, does not specifically describe what is meant by message format. 

In the previous paragraphs, Humpleman makes repeated references to the "formats 
capable of representing objects and their respective methods" for example, "C, XML, or other 
formats-" {Humpleman, col. 12, lines 38-40). Also, "[t]he second block provides a format for 
representation of an API in XML form for all devices." (Humpleman, col. 12, lines 42-43), 
[D]uring run-time, incoming XML form method messages . . . from Service B are converted to 
the API format created by the compiled application C code for Service A." (col. 12, lines 60-62), 
In each of these cases, Humpleman refers to the language format of the interface file* e.g., 
whether it is in an API format, XML format, C format, etc. Hence, the message format clearly 
differs from the "the service control protocol compri$[ing] plural network messages having a 
content and a sequence" recited in claim 25. Thus, claim 25 is not anticipated by Humpleman^ 
and is therefore in condition for allowance. 

Independent claims 32, 33, 38, 42, 48, and 51 respectively recite "storing a dynamically 
discoverable definition of the computing device, the definition including a set of instructions to 
define a network data messages protocol through which a series of network data messages are 
communicated to access a service on the computing device", "a second set of XML-based code 
strings that define one or more services exposed by the device, the second set of XMI^based 
code strings including data to create service specific data messages, wherein the second set of 
XML-based code strings comprises: a service type element, a control URL element, an event 
subscription URL element, and a service control protocol declaration element, wherein the 
service control protocol includes a contract to define interaction with the one or more services 
exposed by the device through plural network messages having a content and a sequence^ "a 
service description written in an XML-based language to describe at least one service supported 
by the controlled device, the service description describing how to access the at least one service 
supported by the controlled device through a set of XML-based service strings, the set of XML- 
based service strings comprising in part a network message protocol definition to describe 
interaction between the at least one service supported by the controlled device via plural 
network messages having a content and a sequence", "a description means, responsive to a 
description request received by the computing device on a network, for sending a description 
message based on the description that defines interaction via data messaging with the computing 
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device oyer the network", "self-describing data stored in the memory and written in an XML- 
based language, the self-describing data describing how to operate the computing device and 
identifying a set of attributes of the computing device, wherein a subset of the attributes define a 
service control protocol comprising a set of network messages having an attribute-defined 
content and an attribute-defined sequence?*, and "multiple controlled devices configured to 
dynamically self-bootstrap onto the network, individual controlled devices comprising a device 
description to describe attributes of the computing device and a service description to describe 
one or more services exposed by the computing device, the device and service description 
defining a messaging protocol, the device and service descriptions being written in an XML- 
based language." (Emphasis added). For at least similar reasons to the ones described above, 
Applicants believe these claims are in condition for allowance. 

The remainder of the claims (26-27, 30-31, 33-34, 36-37, 39-41, 44^47, 50, 52-53, 58-59, 
and 63-72) depend from an independent claim and are therefore also in condition for allowance. 

D, Conclusion 

For at least the foregoing reasons, Applicants believe that the rejections asserted in the Office 
Action should be withdrawn. Therefore, claims 25-27, 30-34, 36-42, 44-48, 50-53, 58-59, and 
63-72 are in condition for allowance and such action is earnestly solicited. The Examiner is 
respectfully requested to contact the undersigned by telephone if it is believed that such contact 
would further the examination of the present application. 



One World Trade Center, Suite 1600 
121 S.W. Salmon Street 
Portland, Oregon 97204 
Telephone: (503)226-7391 
Facsimile: (503)228-9446 



Respectfully submitted, 



KLARQUIST SPARKMAN, LLP 



By 
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